值班工程師請 Agent 查服務延遲，Agent 選了 query_metrics，查詢也成功了。若後來發現它查到另一個團隊的資料，我們就得回頭找：誰交辦這次工作、哪版程式選了目標、哪條規則放行，以及當時到底發生什麼。只知道工具在允許清單裡，還不足以回答這些問題。

Day 4 已用兩筆目標不同的查詢說明工具名稱授權的限制。這篇把視角拉到整條操作路徑，整理一套能拿來安排補強工作的盤點方法。

這些問題散落在 IdP、Agent runtime、Gateway、Tool server 與觀測系統之間，單看任何一個產品都看不完整。於是我把一筆具體動作放到桌上，固定追四件事：誰在行動、執行的是哪一版、哪裡能拒絕、事後能不能重建。後文會用 Identity、Provenance、Enforcement、Traceability 當作這四個問題的簡稱。

產品架構圖看不到的接縫

我最初也按照產品分類。身分系統負責登入，Gateway 負責 routing 和 policy，版本目錄記錄有哪些 Agent，Grafana LGTM 收 logs、metrics 和 traces。圖上的每個方框都有名字，也很容易分配 owner。

拿事故問題去問時，這張圖卻答不出來。身分系統認得值班工程師，下游事件不一定還保留他的身分。版本目錄找得到 Agent，執行時載入的程式卻可能已經換了。Gateway 留下一筆 ALLOW 或 DENY，仍然不能取代資源端的授權。Trace 若沒有 Agent revision 和 policy version，值班的人也很難對回當時的決定。

所以我不再先問「平台有沒有某個產品」，而是沿著同一筆 request 問：它經過每個元件時，原本知道的身分、版本和決定還剩下多少？

先選一筆真的會發生的動作

盤點時先限定一筆操作。例如值班工程師交辦 Agent 查 payments-api 的延遲，Agent 選擇 query_metrics，執行程式再呼叫工具、收下結果。把這條路徑上的角色與動作對回既有 Google ADK Lab，會得到下面的紀錄：

synthetic-user-sre-oncaller
  → sre_investigation_agent
  → runtime workload
  → query_metrics(service="payments-api")
  → synthetic metrics result

這條 Lab 路徑只會回傳固定的合成指標，synthetic-user-sre-oncaller 也只是 session label。環境很小，哪些證據真的存在、哪些只是名稱，看得反而更清楚。

如果一開始就評估「整個 AI 平台」，幾乎每個答案都只能寫成「視情況而定」。限定到這筆 request 後，問題就具體了：這個 session label 是否經過驗證、執行時載入哪一版 Agent、query_metrics 在哪裡能被拒絕，以及 Tool result 能否和前面的模型提案、政策判斷串回同一條事件。

這條 Action Path 的盤點結果

把 Day 1–4 的結果放回 query_metrics 這條路徑後，四個問題並沒有一起得到答案：

表中的 PARTIAL 是「目前能回答一部分」，UNKNOWN 是「這次執行沒有留下答案」。代碼方便填 Checklist。排工作順序時，我們還是得回到具體動作，判斷哪個缺口最可能讓它失控。

Provenance 最容易被 source repository 誤導。Repo 裡看得到 Agent 定義，只能證明這份程式碼存在，不能證明某次 request 跑的就是這一版。要回答事故當下執行了什麼，至少得把 revision 或 artifact digest 綁進 deployment，再把同一個識別資料寫進執行事件。否則程式碼 review 得再完整，事件和受審版本之間仍然接不起來。

Enforcement 和 Traceability 也不能互相代替。Callback 成功擋過 delete_demo_database，說明副作用前有拒絕點，但沒有補上按呼叫者與目標資源決定權限的能力。Ordered events 能重播模型提案、policy decision 和 Tool result。若當時沒記下 Agent revision 或下游憑證，事後也無法憑空補回。

從四個缺口選下一個工作

我把這四個問題整理成 Agent Governance 四問 Checklist。拿自己的 Agent 使用時，先挑一個實際會做的動作，再查它在每個邊界留下什麼。完整狀態代碼和填寫方式放在 Checklist，盤點時可沿著同一筆查詢找缺口。

四格不能平均成一個治理分數。唯讀 Metrics Agent 先要處理查詢範圍與呼叫者歸屬。能修改 Kubernetes Deployment 的 Agent，還得確認它用哪個憑證、對哪個資源執行變更。兩種動作的優先順序不會一樣。

這次我會先補呼叫者身分。Agent 版本還沒和執行事件綁定，確實是缺口。不過眼前的 policy 連 Human 是誰都無法驗證，query_metrics 因此無法按人與目標資源授權。先把身分接進這條路徑，比先建立完整的 Agent 版本目錄更能改變當下的判斷。

synthetic-user-sre-oncaller 目前只是 session label。要讓 Gateway 和 MCP 根據呼叫者做決定，下一步得換成可驗證的 principal，再說清楚 issuer、audience、role 和 scope 各在哪一站使用。

當時我們已經用 Keycloak 跑通企業 IdP、JWT role 與 Gateway 到 MCP 的 Tool RBAC。技術驗收成功後，接下來要決定的是團隊準備承接企業級 Identity Center，還是先替少數 AI 服務提供一個較小的 identity bridge。Day 6 會從這個組織邊界開始。